Use Git branches/tags for versioning #774
Conversation
@@ master #774 diff @@
==========================================
Files 485 485
Lines 20599 20599
Methods 0 0
Messages 0 0
Branches 2912 2912
==========================================
Hits 3650 3650
Misses 16542 16542
Partials 407 407
|
|
Test failure :( |
|
Can we bump down the versionCode and versionName in master for this PR? |
|
I'm curios about @BenjiLee 's question too. But other than that 👍 |
|
Ah, nvm about bumping the versionCode/Name. I see the change now. |
|
Tried to created a build with a branch called rc/3.4.666, no version displayed Looks like |
|
Additionally, Fabric is reporting the build as 0.0 (0) |
|
@BenjiLee Fixed your issue; strange that it still built fine. Also fixed Travis |
ghost
force-pushed
the
bguertin/git_versioning
branch
from
0170e3d
to
132f486
Compare
|
I am wondering how this solution is going to work with what we talked about yesterday. If we have nightly builds. Are they all going to be on an RC branch? Should it be a part of the build automation process to create a new RC branch every time we run the script? I am wondering if another option of implementing this JIRA ticket is to derive the int number from the timestamp. |
|
We can always create a different trigger for nightly builds. For example, if there is a branch called nightly/2.5.1 it can kick off the build. |
|
We could derive the int from the timestamp. Is there a specific reason to use timestamps? |
|
No, the only reason I suggested timestamps is that it's unique and always increasing. My thought was that we modify the Gradle script to convert the time stamp to a int number automatically. Gradle could also take a version int parameter that would override this. @bguertin What are your thoughts? I don't mind implementing, BTW. |
|
The version int is only important for Google Play distribution, our testing builds have no reason to depend on it's value or to increment it. I think it is in our best interest to forget it exists, and rely only on the semantic version. Like Chris said, we could easily customize the nightly build (or any build) to use a particular version if we need to. If building off master right now, it will use the last annotated tag in master (i.e. the output of |
|
OK. That works. On Tue, Jul 19, 2016 at 11:06 AM, Brian @ edX notifications@github.com
Regards, Marc DiNino |
|
Note, this strategy also implies that every submission to Google Play should (in fact, MUST) be accompanied by an increase in the semantic versionName string. I think that's a good thing, but please speak up if you foresee any issue with that. I've used this strategy for other apps in the past without issue. |
|
It think it should be OK. On Tue, Jul 19, 2016 at 11:10 AM, Brian @ edX notifications@github.com
Regards, Marc DiNino |
|
👍 |
Description
MA-2314
The version name (and version code) will now be determined automatically by using, in this order:
BRANCHenvironment variable (for Travis CI)git describeFor a branch / tag to be considered, it must start with
rc/orrelease/prefix. E.g.rc/2.5.0orrelease/2.6.The version code will be based on the semantic version, allowing 3 digits between each decimal. For example, the version
2.3.67will result in a version code of2003067.To quickly see what version would be used if you were to build right now, you can use the new gradle
versiontask, for example:BRANCH=rc/2.3.0 ./gradlew --quiet versionwhich will print2.3.0 (2003000)Travis CI
Travis does not expose the branch or fetch tags by default, so I updated the script to expose a
BRANCHas an environment variable, as well as fetch the tags, so that both branch / tag based versioning will work on Travis as well.Reviewers
If you've been tagged for review, please check your corresponding box once you've given the 👍.